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1. Introduction 

Recently, there have been several publications on relay attacks on contactless smartcards 
and secure element-enabled mobile devices [21 [3j HI [5j EJ HH H2]. However, relay attacks 
on contactless smartcards are not new. In 2005, Hancke [4j first showed that it is possible 
to relay contactless smartcard communication (ISO/IEC 14443 [7]) over longer distances 
through an alternative communication channel. Kfir and Wool [8j describe a similar 
system and also show that the relay device used to access a victims card can be up to 50 
centimeters away from the card when using additional amplification and filtering. 



A relay attack can be seen as a simple range extension of the contactless communication 
channel (see Fig. [I]). Thus, an attack requires three components: 

1. a reader device (often called mole [4] or leech [8j) in close proximity to the card 
under attack, 

2. a card emulator device (often called 'proxy [4J or ghost [8j) that is used to commu- 
nicate with the actual reader, and 

3. a fast communication channel between these two devices. 

The attack is performed by bringing the mole in proximity to the card under attack. 
At the same time, the card emulator is brought into proximity of a reader device (POS 
terminal, access control reader...) Every command that the card emulator receives from 
the actual reader is forwarded to the mole. The mole, in turn, forwards the command to 
the card under attack. The card's response is then received by the mole and sent all the 
way back through the card emulator to the actual reader. 

This type of attack cannot be prevented by application-level cryptography (e.g. encryp- 
tion) [H [5]. The problem is, that the relay attack is a simple range extension of the 
contactless interface, so neither the mole nor the card emulator need to "understand" the 
actual communication. They simply proxy any bits of data they receive. 

As existing cryptographic protocols on the application layer cannot prevent relay attacks, 
several alternative methods have been identified to prevent or hinder relay attacks [4J, [5l [8] : 

1. The card's radio frequency interface can be shielded with a Faraday cage (e.g. alu- 
minium foil) when not in use. 

2. The card could contain additional circuitry for physical activation and deactivation. 

3. Additional passwords or PIN codes could be used for two-factor authentication. 



1.1 Relay Attack 



Applying recent secure element relay attack scenarios to the real world: 
Google Wallet Relay Attack 



Michael Roland < michael.roland@fh-hagenberg.at > 




3 




• Hagenberg • Linz • Steyr • Wels 




f | 

Smartcard 
Reader 



(a) without relay 














( 


^ Mole 




Proxy 






A (Relay Reader) 


-► 


(Card Emulator) 















Smartcard 
Reader 



(b) with relay 

Figure 1: Communication between a smartcard and a reader. 



4. Distance bounding protocols can be used on fast channels to determine the actual 
distance between the card and the reader. 

Other measures - like measurement of command delays to detect additional delays induced 
by relay channels - have been identified as not useful. For instance, Hancke et al. [5j 
conclude that the timing constraints of ISO/IEC 14443 are too loose to provide adequate 
protection against relay attacks. 



1.2 Next Generation Relay Attack 

The threat potential of relay attacks was mitigated by the fact that all relay scenarios 
required physical proximity (less than one meter) to the device under attack. However, 
recent research [HJ [12] follows a different approach. Instead of accessing a device's se- 
cure element through the external (contactless) interface, it is accessed from the device's 
application processor through the internal interface. While the original relay attack re- 
quired mole hardware in physical proximity of the device under attack, pure software on 
an attacked device's application processor is enough. 

The complete relay system, as suggested by [11] and verified in [12] is shown in Fig. [2| It 
consists of four parts: 

• a mobile phone (under control of its owner/legitimate user), 
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• a relay software (under control of the attacker), 

• a card emulator (under control of the attacker), and 

• a reader device (e.g. at a point-of-sale terminal or at an access control gate). 



r NFC-enabled Mobile Phone 






8] 

e.g. TCP/IP 
connection 

> 


Card Emulator 




^Application Processor ^ 


^ Card Emulator Software ^ 

* t 


1 Rement \S Relay ^^NetworkY 
^ Element J^ Software J^ API | 


Network API ^ Q Card Emulation API ^ 

t 




Secure Element 


V^NFC hardware capable of card emulation^-^ 
NFC/RFID link M -» 



Point-of-Sale Terminal # ]# 



Figure 2: Relay scenario: Relay software is installed on the victim's phone. The software 
relays APDUs between the secure element and the card emulator across a network (cellular 
network, WiFi, Bluetooth...) The card emulator emulates a contactless smartcard that 
interacts with a card reader (point-of-sale terminal, access control reader...) The card 
emulator routes all APDU commands received from the point-of-sale terminal through 
the network interface to the relay software on the victim's mobile phone. As soon as the 
response APDU is received from the relay software, it is forwarded to the reader. 



The relay software is installed on the victim's mobile phone. This application is assumed 
to have the privileges necessary for access to the secure element and for communicating 
over a network. These privileges can be either explicitly granted to the application or 
acquired by means of a privilege escalation attack. The relay application waits for APDU 
commands on a network socket and forwards these APDUs to the secure element. The 
responses are then sent back through the network socket. 

The card emulator is a device that is capable of emulating a contactless smartcard in 
software. The emulator has RFID/NFC hardware that acts as a contactless smartcard 
when put in front of a smartcard reader. The emulator software forwards the APDU 
commands (and responses) between a network socket and the emulator's RFID/NFC 
hardware. 

The flow of relayed smartcard commands (APDUs) between the smartcard reader and the 
secure element is shown in Fig. |3| The command APDUs (C- APDUs) received from the 
point-of-sale terminal are routed through the card emulator and over a wireless network 
to the victims device. There, the relay app forwards the C- APDUs to the secure element. 
The corresponding responses (R- APDUs) generated by the secure element are routed all 
the way back (through the relay app, the wireless network and the card emulator) to the 
POS terminal. 
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Figure 3: Flow of relayed smartcard commands (APDUs) between a smartcard reader 
and a secure element. The command APDUs (C-APDUs) received from the point-of- 
sale terminal are routed through the card emulator and over a wireless network to the 
victims device. There, the relay app forwards the C-APDUs to the secure element. The 
corresponding responses (R- APDUs) generated by the secure element are routed all the 
way back (through the relay app, the wireless network and the card emulator) to the POS 
terminal. 



1.3 Access to the Secure Element 

Various schemes for access control to the secure element are analyzed in [TT] . While some 
of them provide sophisticated access control capabilities, all of them have one significant 
flaw. They all rely on the mobile device's operating system (excuted on the application 
processor) to perform access control enforcement. Thus, in all cases, the secure element 
(secure component) blindly trusts the operating system's/application processor's (i.e. in- 
secure component's) access control decisions. Therefore, once an application passes or 
bypasses(!) the security checks performed by the operating system, it can exchange (ar- 
bitrary) APDUs with the secure element. 

Consequently, in the worst-case scenario, root access to the operating system is required to 
bypass these security checks. However, considering the current trend in privilege escalation 
exploits for various mobile device platforms (cf. [12j), it is assumed that an arbitrary 
application can gain elevated or even root privileges on most platforms that are currently 
in the field. 

For instance, for the Android platform, recent exploits comprise mempodroid (Android 4.0 
and later), Levitator (up to Android 2.3.5), zergRush (up to Android 2.3.3), GingerBreak 
(up to Android 2.3.3), ZimperLich, Killing InTheName, RageAgainstTheCage, Exploid ... 
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Figure 4: Histograms of delay between command and response at the reader side for the 
APDU "SELECT Issuer Security Domain (card manager) by AID" (C-APDU: 13 bytes, 
R-APDU: 105 bytes) for 5000 repetitions. The histogram is divided into 160 bins. Each 
bin has a width of 50 ms. The last bin also contains all measurements above 8000 ms. |(a)| 
is zoomed from to 50ms with 1-ms-bins. |(b)| is zoomed from to 150ms with 5-ms-bins. 
(c)|is zoomed from to 500 ms with 5-ms-bins. 



1.4 Suitable Relay Channels 

In [12], the delay times induced by relaying APDU communication over various channels 
are evaluated. Fig. [4] shows a comparison of four different paths for secure element access: 

1. Direct access to the secure element with an external reader (i.e. no relay), 

2. direct access to the secure element with an app on the phone, 

3. access through the relay system using a direct WiFi link between the phone and the 
card emulator, 
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4. access through the relay system using the mobile phone network and an Internet 
link between the phone and the card emulator. 

Direct access to the secure element through the contactless interface (path [j]) takes about 
30 ms. On-device access to the secure element (path [2]) takes significantly longer (50 to 
80 ms). A WiFi connection (path [3]) adds an additional delay in the range of 100 and 
210 ms. For path[4j the delays start at about 200 ms and have a significant peak around 
300 ms. Thus, the internet link adds at least 150 ms of delay. But for more than half of 
the measurements the total command-response delay was above 1 second. 

In practice there are no (strict) timing requirements for payment applications. ISO/IEC 
14443-4 provides a frame waiting time extension so that no timing requirements apply 
to the APDU layer. The EMV specification for contactless payment systems [1] specifies 
a limit of 500 ms for a contactless payment transaction as a whole (where a transaction 
already comprises multiple APDU command-response sequences.) Consequently, both 
relay scenarios are likely to fail these timings. However, a payment terminal is not required 
to interrupt a transaction if it takes longer than this limit. The limit is merely meant 
as a benchmark target to maintain user experience. For example, the PayPass terminals 
used in recent roll-outs in Austria (see Fig. [7| do not enforce any such timings. Also, 
cloud-based secure element solutions (cf. [10J) like those provided by YES- wallet^] will 
only work with relaxed timing requirements. 

2. Applying the Attack to a Real-World Payment System 

Videos of the successful relay attack are available on YouTube: 

• Initial video proof: 

|http: / /www.youtube.com/watch?v= hx5nbkDy6tc 

• Re-take, better quality: 

|http: / /www.youtube.com/watch?v=_R2JVPJzufg 

To verify the applicability of the software-based relay attack, it has been applied to an 
existing payment system. Google Wallet has been chosen for several reasons: 

• Google Wallet is already in use by many users. (Google Play Store listed more than 
500,000 installation^ in early 2012. Meanwhile Google Wallet has over 1,000,000 
installations.) 



1 


http://www.yes-wallet.com/ 




1 


https://play.google.com/store/apps/details?id=com. google, android, apps.walletnfcrel 
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• It is based on EMV payment standards (specifically MasterCard PayPass using 
the EMV mag-stripe mode) and can be used with any point-of-sale terminal that 
supports PayPass contactless credit card transactions. 

• The Android source code is publicly available. Thus, it was fairly easy to explore 
its NFC software stack and its hiddeij^] secure element API (com. android. nfc_ 
extras). 

• Google Wallet is known to be installed by many users on rooted devices (mainly 
to circumvent operator and location restrictions). This means that the operating 
system's security measures are already weakened/bypassed on those phones. 

• For non-rooted devices, there either already exist privilege escalation exploits (up to 
Android 2.3.5 and on Android 4.0+) or it is assumed that such exploits will appear 
soon (cf. [T3j ) . Additionally, once an exploit is found/known, it takes several month 
until devices in the field are patched. 



2.1 Google Wallet 

Google Wallet is a container for payment cards, gift cards, reward cards and special offers. 
It consists of an Android app with a user interface and JavaCard applets on the secure 
element. The user interface is used to unlock the wallet (when it was previously locked 
by a PIN code), to select the currently active card, to find specific offers and to view the 
transaction history. The analysis and attack described in this paper have been performed 
with version I.l-R52v7 of the Google Wallet app and the secure element applets installed 
in February 2012. 

Google has quickly responded to our discoveries by providing fixes in more 
recent versions of Google Wallet. For instance, the relay attack could not 
be reproduced with secure element applets installed in June 2012. With 
recent upgrades of the Google Wallet app, also existing users received the 
necessary fixes of the secure element applets and are no longer vulnerable 
to the relay attack scenario described in this paper. 



Upon first start, the Google Wallet app initializes the secure element and installs a PIN 
code that is necessary for using the Google Wallet app's user interface. During initializa- 
tion several applets are installed and personalized on the secure element using GlobalPlat- 
form card management. Specifically, a secure channel based on the secure channel protocol 
SCP02 is established between the secure element and a remote server which performs the 
card management through this authenticated and (partly) encrypted channel. 



3 Hidden means that it is not included in the public software development kit. 



Applying recent secure element relay attack scenarios to the real world: 
Google Wallet Relay Attack 

Michael Roland < michael.roland@fh-hagenberg.at > 



r 




• Hagenberg • Linz • Steyr • Wels 



Executable load-files on the secure element after initialization: 

• A0000000035350: Issuer Security Domain/Card Manager 

• A00000000410: MasterCard Credit Card 

• A00000047610: Unknown (Google) 

• A0000004761000: Unknown (Google) 

• A0000004761001: Unknown (Google) 

• A0000004761002: Unknown (Google) 

• A00000047620: Google Wallet 

• A00000047630: Google Mifare Access 

• 785041592E: EMV Payment System Environment 
Applets used by Google Wallet and payment terminals: 

• A0000000041010: MasterCard Credit Card 

• A0000000041010AA54303200FF01FFFF: MasterCard Google Prepaid Card 

• A0000004762010: Google Wallet On-Card Component 

• A0000004763030: Google Mifare Access Applet 

• 325041592E5359532E4444463031: EMV Proximity Payment System Environment 
(PPSE, 2PAY.SYS.DDF01) 

Google Wallet On-Card Component and Google Mifare Access Applet are only selectable 
through the secure element's internal mode but cannot be selected through the contactless 
interface. 

Google Wallet APDU commands: 

• 00A4040007A000000476201000: Select Google Wallet on-card component 

• 80E200AA00: Unlock Google Wallet (This command is used after successful PIN 
verification in the Google Wallet app. The PIN is not verified by the on-card com- 
ponent.) 

• 80E2005500: Lock Google Wallet 

• 80CA00A500: List installed payment cards(?) 

• 80F24000024F0000: Similar to GlobalPlatform GET STATUS for applications and 
supplementary security domains (?) 
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• 80F00101124F10A0000000041010AA54303200FF01FFFF00: Disable Google Prepaid 
Card(?) 

• 80F00201124F10A0000000041010AA54303200FF01FFFF00: Enable Google Prepaid 
Card(?) 

For a successful relay attack, it is necessary to select the Google Wallet on-card component 
and unlock the wallet. After this, the default payment card can be accessed through the 
secure element's internal mode. No user interaction is required. If other cards besides 
the MasterCard Google Prepaid Card are installed into the wallet, additional commands 
might be necessary to enable the desired payment card. 



2.2 Google Prepaid Card 

The Google Prepaid Card uses the EMV Contactless Specifications for Payment Systems 
and is a MasterCard PayPass card. It only supports the Mag-Stripe mode with dynamic 
CVC3 (card verification code) and online transaction^} 

During a Mag-Stripe mode transaction, the following command-sequence is performed by 
a POS terminal: 

1. POS terminal: Select Proximity Payment System Environment (PPSE) (see Table[T]) 

2. Card: Confirm selection and respond with a list of supported EMV payment appli- 
cations (see Table [2]) 

3. POS terminal: Select MasterCard Google Prepaid Card (see Table [3]) 

4. Card: Confirm selection and respond with application details (e.g. that it is a Mas- 
terCard) (see Table [3]) 

5. POS terminal: Get processing options (see Table [5]) 

6. Card: Respond with supported mode (Mag-Stripe only, online transactions only, 
no cardholder verification...) and with the location of the Mag-Stripe data file (see 
Table g 

7. POS terminal: Read first record data file (see Table [7]) 

8. Card: Return Mag-Stripe track 1 and track 2 data (see Table [8]) 

9. POS terminal: Request computation of cryptographic checksum for a given unpre- 
dictable number (UN) (see Table [9]) 



4 Note that the attack described in this paper is expected to also work with EMV mode (also known as 
Chip & PIN), as long as cardholder verification (PIN code) is not required for the transaction. 
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10. Card: Return application transaction counter (ATC) and dynamically generated 



CVC3 for track 1 and track 2 (see Table 10) 



2.3 Android's Secure Element API 

Android's secure element API (com. android. nfc_extras) is available since Android 
2.3.4. It consists of two classes: Nfc Adapter Extras (see B.l[ ) and NfcExecutionEnviron- 



ment (see B.2). NfcAdapterExtras is used to enable and disable external card emulation 
and to retrieve an instance of the embedded secure element's NfcExecutionEnvironment 
class. NfcExecutionEnvironment is used to establish an internal connection to a secure 
element and to exchange APDUs with it. 

In Android 2.3.4, this API could be accessed by any application that held the permission 
to use NFC. In later versions, a special permission named com. android, nfc .permis- 
sion. NFCEE_ADMIN is required. This permission is only granted to applications that are 
signed with the same certificate as the NFC system service. Starting in Android 4.0, the 
permission system for the secure element API has fundamentally changed. Permissions to 
access the secure element are now granted through an XML file. This XML file contains 
a list of certificates that are granted access. However, applications with root access can 
easily obtain the permission to access the secure element for any of these access control 
mechanisms. 



2.4 The Relay App 

The relay app, a purely Java-based Android app, is a simple TCP client that maintains 
a persistent TCP connection to a remote server (the card emulator). When the card 
emulator requests access to the secure element, a connection is established through the 
NfcExecutionEnvironment object. Then, the Google Wallet on-card component is selected 
and the unlock command is sent. The relay app then listens for C- APDUs on its network 
interface and forwards them to the secure element. The R- APDUs from the secure element 
are transmitted back to the card emulator. When the transaction is complete, the Google 
Wallet on-card component is selected again and the lock command is sent to lock the 
wallet. 

For this test scenario, the relay app has been manually granted the permissions necessary 
to access the secure element. However, privilege escalation exploits could be integrated 
into future versions of the app. For easier integration of future exploit codes, a privilege 
escalation framework (cf. [6j) could be embedded into the app. 

Additionally, the test app has a foreground component that needs to be started manu- 
ally. Moreover, the connection to the card emulator needs to be confirmed by the user. 
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However, the app could be started automatically on device boot-up and run completely 
in the background. 

To roll out the relay app to user's devices, it could be integrated into any existing app 
downloaded from Google Play Store. The infected app could then be re-published on 
Google Play Store under similar (or even identical) publisher information and with the 
same app name as its original To specifically target users of rooted devices, an app that 
already requires root permissions could be used as a base for code injection. 



2.5 The Card Emulator 



For this proof-of-concept a simple card emulator has been built from a notebook computer 
and an ACS ACR 122U NFC reader (Fig. [5]). This NFC reader supports software card 
emulation mode and is available for less than EUR 50 (including taxes and shipping) from 
touchatag. com[^| Several examples on how to use this device in card emulation mode can 
be found on the wefcQ 




Figure 5: Card emulator made from a notebook and an ACS ACR 122U NFC reader. 



5 Note that Google started to combat this with recent updates to the Google Play Developer Program 

Policy 

6 http: / / store.touchatag.com/acatalog/touchatag_starter_pack.html 
7 E.g. on http://www.libnfc.org/ 
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The card emulation software (written in Python) contains a TCP server that listens for 
incoming connections from the relay app. Once a TCP connection has been established, 
the emulator goes into card emulation mode and waits for a POS terminal. When the 
card emulator detects activation by a POS terminal (or any smartcard reader), it requests 
access to the secure element through the relay app. Then, all received C-APDUs are 
forwarded through the network interface to the relay app and all R-APDUs received from 
the relay app are returned to the POS terminal. When the RF field is deactivated, the 
connection to the secure element is closed. 

The custom card emulator in Fig. [5] has a form factor that will certainly raise suspicions 
at the point-of-sale. However, there already exist devices with an accepted form factor 
(i.e. that of a mobile phone, see Fig. [6]) with support for software card emulation. E.g. all 
BlackBerry devices with NFC that are equipped with the BlackBerry 7 platform support 
software card emulation mode. Moreover, recent patches [TU [15] to the CyanogenMod 
firmware for Android devices enable software card emulation for Android NFC devices that 
are based on the PN544 NFC controller. Besides their form factor, mobile phones have 
anonther advantage when used as card emulator platform for relay attacks: They already 
contain the same network interfaces as the device under attack [10] . The viability of a 
BlackBerry device as card emulator platform for relay attacks has already been verified 
by Francis et al. [3]. 



: : : BlackBerry 




Figure 6: BlackBerry 9380 supports software card emulation. (Source: 
http:/ /www. phonearena.com/news/BlackBerry-Curve-9380-announced-the- first-ever- 
Curve- with-a-touchscreen_id23783) 
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2.6 Point-of-Sale (POS) Terminal 

The Google Wallet relay attack has been successfully tested together with a POS terminal 




Figure 7: POS terminal (HYPERCOM Artema Hybrid) with contactless module (Vi- 
VOtech 5000), as used in recent roll-outs at Schlecker and Zielpunkt in Austria. (Source: 
nfc.cc [9]) 



2.7 Viability of the Google Wallet Relay Attack 

For this attack only an NFC reader device (available for less than EUR 50), a notebook 
computer and some average programming skills were necessary. A BlackBerry with soft- 
ware card emulation support is available for less than EUR 300. An additional EUR 20 
is necessary for a publisher account on Google Play Store. 

When the relay app is running on many devices, a "bot network" of Google Wallets 
could be created. The attacker could then perform some kind of "load balancing" to 
evenly distribute payments among devices and to select a device with a stable network 
connection for each payment transaction. 
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3. Possible Workarounds 
3.1 Timeouts of POS Terminals 

An easy, but potentially unreliable, measure to prevent relay attacks would be the en- 
forcement of short timeouts (e.g. those specified by the EMV specifications) for payment 
transactions on the POS terminals. Transactions taking longer than this timeout should 
be interupted or discarded. While this measure will prevent most long-distance relay 
scenarios, relays over shorter distances and fast communication channels might not be 
rejected. Also, installing such tight timeouts will prevent cloud-based EMV applications 
(cf. [10J and YES-wallefl. 



3.2 Google Wallet PIN Code Verification 

With the tested implementation of the Google Wallet app (version I.l-R52v7), the PIN 
code that protects the Google Wallet is only verified within the mobile phone app. The 
on-card component does not verify this PIN code. Instead, the on-card component is 



s http://www.yes-wallet.com/ 
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controlled by simple lock and unlock commands (see 2.1). 



PIN code verification could be handled by the on-card component on the secure element 
instead of by the app on the mobile phone's application processor. After all, PIN code 
verification is a core component of smart cards anyways. In that case, the attacker would 
need to know the wallet's PIN code to conduct a successful attack. 

On a rooted device, an attacker might still be able to sniff the PIN code (while it is entered 
by the user) by capturing the screen and the touch events. However, this is significantly 
more difficult than sending a simple unlock command to the secure element. 



3.3 Disabling Internal Mode Communication for Payment Applets 

Recent secure elements (like the one embedded into the Nexus S) provide instruments to 
distinguish between external communication (contactless interface) and internal commu- 
nication (application processor) from within a JavaCard applet. In addition, the secure 
element may have the capability to completely disable a certain interface on a per-applet 
basis. These capabilities could be used to disable internal mode communication for all 
payment applets and consequently disable their vulnerability for software-based relay at- 
tacks. 

The disadvantage of this workaround is that the secure element cannot be used for future 
on-device secure payment applications (e.g. EMV payment in the mobile phone's web- 
browser). Such applications would, however, be one of the major benefits of having a 
secure element inside a mobile phone. 

I Note: This method has been used to circumvent relay attacks in more recent 
versions of Google Wallet. 
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Appendix A. APDUs for Mag-Stripe Mode Transactions 



Table 1: Select Proximity Payment System Environment (PPSE): C-APDU 



CLA 


00 








Inter-industry class 


INS 


A4 








Select 


PI 


04 








Selection by DF name 


P2 


00 








Return FCI template 


Lc 


0E 










DATA 


32 


50 


41 


59 2E 


Proximity Payment System Environment (2PAY.SYS.DDF01) 




53 


59 


53 


2E 44 






44 


46 


30 


31 




Le 


00 
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Table 2: Select Proximity Payment System Environment (PPSE): R-APDU 



DATA 6F 


3A 


84 


OE 


32 


Tag: FCI template (6F) 


50 


41 


59 


2E 


53 


Length: 58 (3A) 


59 


53 


2E 


44 


44 


Value: (constructed) 


46 


30 


31 


A5 


28 


Tag: DF name (84) 


BF 


OC 


25 


61 


15 


Length: 14 (OE) 


4F 


10 


AO 


00 


00 


Value: 2PAY.SYS.DDF01 (325041592E5359532E4444463031) 


00 


04 


10 


10 


AA 


Proximity Payment System Environment 


54 


30 


32 


00 


FF 


Tag: Proprietary information encoded in BER-TLV (A5) 


01 


FF 


FF 


87 


01 


Length: 40 (28) 


01 


61 


OC 


4F 


07 


Value: (constructed) 


AO 


00 


00 


00 


04 


Tag: FCI issuer discetionary data (BF0C) 


10 


10 


87 


01 


02 


Length: 37 (25) 



Value: (constructed) 

Tag: Application template (61) 
Length: 21 (15) 
Value: (constructed) 

Tag: Application identifier (4F) 

Length: 16 (10) 

Value: MasterCard Google Prepaid Card 

(A0000000041010AA54303200FF01FFFF) 

Tag: Application priority indicator (87) 

Length: 1 (01) 

Value: 1 (01) 
Tag: Application template (61) 
Length: 12 (0C) 
Value: (constructed) 

Tag: Application identifier (4F) 

Length: 7 (07) 

Value: MasterCard credit/debit card 

(A0000000041010) 
Tag: Application priority indicator (87) 
Length: 1 (01) 
Value: 2 (02) 

SW1 90 Success 
SW2 00 
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Table 3: Select MasterCard Google Prepaid Card: C-APDU 



CLA 


00 










Inter-industry class 


INS 


A4 










Select 


PI 


04 










Selection by DF name 


P2 


00 










Return FCI template 


Lc 


10 












DATA 


AO 


00 


00 


00 


04 


MasterCard Google Prepaid Card 




10 


10 


AA 


54 


30 






32 


00 


FF 


01 


FF 






FF 












Le 


00 













Table 4: Select MasterCard Google Prepaid Card: R-APDU 



DATA 6F 


20 


84 


10 


AO 


Tag: FCI template (6F) 


00 


00 


00 


04 


10 


Length: 32 (20) 


10 


AA 


54 


30 


32 


Value: (constructed) 


00 


FF 


01 


FF 


FF 


Tag: DF name (84) 


A5 


OC 


50 


OA 


4D 


Length: 16 (10) 


61 


73 


74 


65 


72 


Value: MasterCard Google Prepaid Card 


43 


61 


72 


64 




(A0000000041010AA54303200FF01FFFF) 












Tag: Proprietary information encoded in BER-TLV (A5) 












Length: 12 (0C) 












Value: (constructed) 












Tag: Application label (50) 












Length: 10 (OA) 












Value: MasterCard (4D617374657243617264) 



SW1 90 Success 
SW2 00 
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Table 5: Get Processing Options: C-APDU 



CLA 


80 


Proprietary class 


INS 


A8 


Get Processing Options 


PI 


00 




P2 


00 




Lc 


02 




DATA 


83 00 


Processing options data object list (PDOL) related data 
Tag: Command template (83) 
Length: (00) 
Value: (empty) 



Le 00 



Table 6: Get Processing Options: R-APDU 



DATA 77 OA 82 02 00 Tag: Response message template (77) 

00 94 04 08 01 Length: 10 (OA) 

01 00 Value: (constructed) 

Tag: Application interchange profile (82) 
Length: 2 (02) 
Value: 00 00 

Bit 1.7 = 0: no offline static data authentication supported 
Bit 1.6 = 0: no standard offline dynamic data authentication 
supported 

Bit 1.5 = 0: no cardholder verification supported 

Bit 1.4 = 0: no terminal risk management is to be performed 

Bit 1.3 = 0: no issuer authentication supported 

Bit 1.2 = 0: no combined DDA/AC generation supported 

Bit 2.8 = 0: only Mag-Stripe profile supported 

others: RFU 

Tag: Application file locator (94) 

Length: 4 (04) 

Value: 08 01 01 00 

Bit 1.8-1.4 = 00001: Short EF = 1 
Bit 1.3-1.1 = 000 

Bit 2.8-2.1 = 00000001: First record to read is 1 
Bit 3.8-3.1 = 00000001: Last record to read is 1 
Bit 4.8-4.1 = 00000000: consecutive records signed in 
Signed Application 

SW1 90 Success 
SW2 00 
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Table 7: Read first record data file: C-APDU 



CLA 


00 


Inter-industry class 


INS 


B2 


Read record(s) 


PI 


01 


Record number 1 


P2 


OC 


Short EF = 1, Read record PI 


Le 


00 
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Table 8: Read first record data file: R-APDU 



ATA 7A 
JJA1 A f U 


OA 


yr 


OO 


Uz 


Tag: Non inter-industry nested data object template (70) 


UU 


Ul 


yr 


oz 


Ub 


.Lengtn. rut) \oA) 


UU 


C\C\ 

UU 


C\C\ 

UU 


UU 


UU 


Value: (constructed) 


QQ 
OO 




DO 


Ub 


UU 


Tag: Mag-Stripe application version number (9F6C) 


UU 


UU 


UU 


Uo 


UO 


-Lengtn. z yuz j 


ob 


on 

zy 


A 1 


OO 


o4 


value, version i ^uu uij 


33 


30 


XX 


XX 


XX 


Tag: Track 1 bit map lor CVC3 (9F62) 


XX 


30 


XX 


XX 


37 


Length: 6 (06) 


XX 


XX 


XX 


XX 


5E 


Value: 00 00 00 00 00 38 


20 


2F 


5E 


31 


37 


Tag: Track 1 bit map for UN and ATC (9F63) 


31 


31 


31 


30 


31 


Length: 6 (06) 


30 


30 


31 


30 


30 


Value: 00 00 00 00 03 C6 


30 


30 


30 


30 


30 


Tag: Track 1 data (56) 


30 


30 


30 


9F 


64 


Length: 41 (29) 


01 


04 


9F 


65 


02 


Value: B5430xxxx0xx7xxxx^/^ 17111010010000000000 


00 


38 


9F 


66 


02 


Format code: "B" (ISO/IEC 7813 Structure B) 


03 


C6 


9F 


6B 


13 


PAN: "5430 xxxx 0xx7 xxxx" 


54 


30 


XX 


XX 


Ox 


Field seperator: 


x7 


XX 


XX 


Dl 


71 


Cardholder: "J" 


11 


01 


00 


10 


00 


Field seperator: 


00 


00 


00 


OF 


9F 


Expiry date: "17"/"11" 


67 


01 


04 






Service code: "101" 



Discetionary data: "0010000000000" 
Tag: Track 1 number of ATC digits (9F64) 
Length: 1 (01) 
Value: 4 (04) 

Tag: Track 2 bit map for CVC3 (9F65) 
Length: 2 (02) 
Value: 00 38 

Tag: Track 2 bit map for UN and ATC (9F66) 

Length: 2 (02) 

Value: 03 C6 

Tag: Track 2 data (9FB6) 

Length: 19 (13) 

Value: 5430xxxx0xx7xxxxD17111010010000000000F 
PAN: "5430 xxxx 0xx7 xxxx" 
Field seperator: "D" 
Expiry date: "17"/"11" 
Service code: "101" 
Discetionary data: "0010000000000" 
Padding: "F" 

Tag: Track 2 number of ATC digits (9F67) 

Length: 1 (01) 

Value: 4 (04) 

SW1 90 Success 
SW2 00 
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Table 9: Compute Cryptographic Checksum: C-APDU 



CLA 


80 


Proprietary class 


INS 


2A 


Compute Cryptographic Checksum 


PI 


8E 




P2 


80 




Lc 


04 




DATA 


00 00 00 80 


Unpredictable number (UN) 



Le 00 



Table 10: Compute Cryptographic Checksum: R-APDU 



DATA 77 


OF 


9F 


61 


02 


Tag: Response message template (77) 


XX 


XX 


9F 


60 


02 


Length: 15 (OF) 


XX 


XX 


9F 


36 


02 


Value: (constructed) 


00 


12 








Tag: CVC3 Track 2 (9F61) 












Length: 2 (02) 












Value: xx xx 












Tag: CVC3 Track 1 (9F60) 












Length: 2 (02) 












Value: xx xx 












Tag: Application transaction counter (ATC) (9F36) 












Length: 2 (02) 












Value: 12 (00 12) 



SWl 90 Success 
SW2 00 
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Appendix B. Android Secure Element API 



B.l Class: NfcAdapterExtras 



package com . android . nf c.extras ; 

public final class NfcAdapterExtras { 

/** Broadcast Action: RF field ON has been detected ( unr e 1 i abl e / wi 11 be removed) 
public static final String ACTI0N_RF_FIELD_0N_DETECTED = 

"com. android . nf c.extras . act ion . RF_FIELD_0N_DETECTED " ; 



/** Get the NfcAdapterExtras for the given NfcAdapter. 
public static NfcAdapterExtras get ( Nf c Adapt er adapter); 



/** Immutable data class that describes a card emulation route, 
public final static class CardEmul at i onRout e { 

/** Card Emulation is turned off on this NfcAdapter. 

public static final int R0UTE_0FF = 1; 

/** Card Emulation is routed to nfcEe when the screen is on, 

* otherwise it is turned off . 
public static final int R0UTE_0N_WHEN_SCREEN_0N = 2; 

/** A route such as R0UTE_0FF or R0UTE_0N_WHEN_SCREEN_0N . 
public final int route; 

/** The NFcExecut i onEnvir onment that Card Emulation is routed to. 
public final Nf cExe cut i onEnvir onment nfcEe; 

public CardEmulat ionRoute ( int route, Nf cExe cut i onEnvir onment nfcEe): 



/** Get the current routing state of the secure element, 
public CardEmulat ionRoute get CardEmul at i onRout e () ; 

/** Set the routing state of the secure element. 

public void set CardEmulat ionRoute ( CardEmulat ionRoute route); 



/** Get the Nf cExe cut i onEnv ir onment for the embedded secure element, 
public Nf cExe cut i onEnvir onment get EmbeddedExe cut i onEnvir onment () ; 



/** Authenticate the client application (if required by the implementation) 

* This method is not used on Nexus S/Galaxy Nexus, 
public void authenticate (byte [] token); 



*/ 



/** Broadcast Action: RF field OFF has been detected (unreliable /will be removed). */ 
public static final String ACTI0N_RF_FIELD_0FF_DETECTED = 

"com. android . nf c.extras . act ion . RF_FIELD_0FF_DETECTED " ; 



*/ 

*/ 
*/ 

*/ 
*/ 
*/ 



*/ 



*/ 



*/ 



*/ 
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B.2 Class: NfcExecutionEnvironment 



1 package com . android . nf c.extras ; 

2 

3 import j ava . io . IOExcept ion ; 

4 

5 public class NfcExecutionEnvironment { 

6 /** Broadcast Action: An ISO-DEP AID was selected. */ 

7 public static final String ACTION_AID_S ELECT ED = 

8 "com. android .nf c.extras . action. AID_SELECT ED" ; 

9 /** Mandatory byte array extra field in ACTI 0N_ AID_SELECTED . */ 
10 public static final String EXTRA_AID = " com . android . nf c.extras . extra . AID " ; 

11 

12 /** Broadcast action: A filtered APDU was received. */ 

13 public static final String ACTI 0N_ APDU.RECEI VED = 

14 "com. android . nf c.extras . act ion . APDU.RECEI VED " ; 

15 /** Mandatory byte array extra field in ACTI ON. APDU.RECEI VED . */ 

16 public static final String EXTRA. APDU_BYTES = 

17 "com. android . nf c.extras . extra . APDU_BYTES " ; 

18 

19 /** Broadcast action: An EMV card removal event was detected. */ 

20 public static final String ACTI 0N_EMV_CARD_REM0VAL = 

21 "com. android . nf c.extras . act ion . EMV_ CARD .REMOVAL " ; 

22 

23 /** Broadcast action: An adapter implementing MIFARE Classic via card emulation 

24 * detected that a block has been accessed. */ 

25 public static final String ACTI ON.MIFARE. ACCESS.DETECTED = 

26 "com. android . nf c.extras . act ion . MIFARE. ACCESS .DETECTED " ; 

27 /** Optional integer extra field in ACTION.MIFARE.ACCESS.DETECTED that provides 

28 * the block number being accessed. */ 

29 public static final String EXTRA .MIFARE .BLOCK = 

30 "com. android . nf c.extras . extra . MIFARE.BLOCK " ; 

31 
32 

33 /** Open the NFC Execution Environment on its contact interface. */ 

34 public void openQ throws IOException; 

35 

36 /** Close the NFC Execution Environment on its contact interface. */ 

37 public void close () throws IOException; 

38 

39 /** Send raw commands to the NFC-EE and receive the response. */ 

40 public byte [] transceive (byte [] in) throws IOException; 

41 } 
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